-
Notifications
You must be signed in to change notification settings - Fork 10k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove the sourceEventType
from the viewer (bug 1757771 follow-up)
#14926
Remove the sourceEventType
from the viewer (bug 1757771 follow-up)
#14926
Conversation
After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the `sourceEventType` is now completely unused and should thus be removed (in my opinion). Furthermore, with these changes, we also no longer need a *separate* internal "save"-event and can instead just use the older "download"-event everywhere.
…dManager` After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the `ChromeActions.download`-method will no longer invoke the `sendResponse`-callback. Hence it should no longer be necessary for the `DownloadManager`, in the MOZCENTRAL viewer, to use `FirefoxCom.requestAsync` since no response is ever provided.[1] For the allocated BlobURLs, they should (hopefully) be released when navigating away from the viewer. --- [1] Note that that was *already* the case, for one of the previous code-paths in the `ChromeActions.download`-method.
/cc @calixteman Should we perhaps wait a few days before landing this PR, to ensure that the patch in bug 1757771 will actually "stick" first? |
/botio integrationtest |
From: Bot.io (Linux m4)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/455a75b0eedc9e1/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.193.163.58:8877/6e4fe889ad79398/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/455a75b0eedc9e1/output.txt Total script time: 4.34 mins
|
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/6e4fe889ad79398/output.txt Total script time: 7.91 mins
|
Yep it's wiser to wait few days. |
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @timvandermeij received. Current queue size: 0 Live output at: http://54.241.84.105:8877/2bc758ca087f46e/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/2bc758ca087f46e/output.txt Total script time: 2.54 mins Published |
Nothing got reverted upstream, so let's do this. Thanks! |
Remove the
sourceEventType
from the viewer (bug 1757771 follow-up)After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the
sourceEventType
is now completely unused and should thus be removed (in my opinion).Furthermore, with these changes, we also no longer need a separate internal "save"-event and can instead just use the older "download"-event everywhere.
[Firefox viewer] Stop using
FirefoxCom.requestAsync
in theDownloadManager
After the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=1757771, that simplified the MOZCENTRAL downloading code, the
ChromeActions.download
-method will no longer invoke thesendResponse
-callback.Hence it should no longer be necessary for the
DownloadManager
, in the MOZCENTRAL viewer, to useFirefoxCom.requestAsync
since no response is ever provided.[1] For the allocated BlobURLs, they should (hopefully) be released when navigating away from the viewer.[1] Note that that was already the case, for one of the previous code-paths in the
ChromeActions.download
-method.